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METHOD AND APPARATUS FOR POINT-OF-SALE PURCHASING 

CROSS-REFERENCE TO RELATED APPLICATIONS 
[0001] This claims the benefit of U.S. Provisional Patent Application No. 60/443,905 filed 
January 31,2003. 

STATEMENT REGARDING FEDERALLY 
SPONSORED RESEARCH OR DEVELOPMENT 

BACKGROUND OF THE INVENTION 
[0002] The present invention relates generally to computer software-based pop-up displays and 
more particularly relates to a software program that monitors input data in real-time to selectively 
initiate an interactive purchase display. 

[0003] Conventional global distribution systems (GDS) and computer reservation systems (CRS) 
are widely known as "legacy" mainframe computer systems that provide access to travel related 
suppliers and vendors. For the sake of clarity and convenience, GDS and CRS systems are 
collectively identified in a non-limiting manner throughout this disclosure synonymously as 
GDS, and more genetically referred to as travel reservation purchase routines. 
[0004] In general, a GDS can be selected from a collection of well-known systems (namely 
Sabre, Abacus, Amadeus, Galileo/ Apollo, and Worldspan) used by travel agents for booking 
travel reservations, such as tours, cruises, and airline tickets for travelers worldwide. The GDS 
system is text based and requires the operator to learn a set of cryptic data entry codes and 
protocol for entering passenger and travel-related data, known as passenger name records (PNR). 
Examples of various data entry fields for the Worldpsan system are illustrated in Table 1. 

[0005] Table 1 



PNR TYPE 


DATA ENTRY CODE 


Specific Date 


T:TAU/9JUL 


Date and Comment 


T:TAU/9JUL/FREEFORM 


Date at Branch Office 


T:TAU/8AUG@CA3 


Agent PCC and Branch PCC 


T : T AU/ 1 MAY/3 M A Y@C A3 


Date/Comment at Branch Office 


T:TAU/8AUG@CA3/FREEFORM 


Date and Multiple-Queue Placement (Max of 6) 


T : T AU/9 JUL/ 1 JULQ5/8 JUNQ4 



Date and Multiple Queue and Queue Category 
Placement 


T:TAU9JUL/1JULQ7*CCT 


House Account (Min 6 Char.) 


T:TAW/28JUL-ACMECO 


House Account with Time 


T:TAW/28JUL-ACMECO-3P 
OR 

T:TAW/28JUL-3P-ACMECO 


House Account..Time/Comment 


T:TAW/8JUL-ACME-9A/DLVR 


Specific Date and Queue Placement at Branch 
unice 


T:TAW/9JULACMECO@CA3/8JUNQl 5/1 
0JULQ14 


House Account with Time at a Branch Office 


T:TAW/28JUL-ACME-9A@CA3 


House Account with Time and Queue Placement 
(jviax oi o) 


T:TAW/28JUL-ACMECO-3P/2JULQ43 


Specific Airport/Carrier/Time 


T:TLORD/TW900A/1JUL 


30 Minutes for UA 


T:TL30 


Follow-up and Place on Queue 12 


T:TL800A/2JUL/CK.SEATS 


Passenger Ticketed 


T:T/ 



[0006] It should be appreciated that the data entry codes above are merely examples of the types 
of codes used in a GDS, and the present invention is not to be limited to those specifically 
identified herein. Rather, the examples in Table 1 are set forth to illustrate examples of the data 
entry codes that are used when booking a travel reservation. Because of the difficulty posed to 
the travel agent in learning the data entry codes, and the time-consuming nature of entering the 
codes, a travel agent may spend a significant amount of time typing when completing a sale. 
[0007] Due to the elimination of airline commissions in 2002, along with overall cuts to the base 
commissions paid by most travel suppliers to travel agencies, travel agencies have sought ways 
to reduce the length of time needed to complete a travel purchase. Agencies further encourage 
their agents to sell products that result in higher commissions, such as travel insurance. 
[0008] What is therefore desirable is a method and apparatus for automatically reminding agents 
operating a GDS to offer travel insurance when appropriate. It would further be desirable to 
automatically update the PNR when such products are sold without requiring substantial data 
entry on the part of the travel agent. 

BRIEF SUMMARY OF THE INVENTION 
[0009] In accordance with one aspect, of the invention, a method is provided for facilitating 
travel insurance sales on a computer system that is receiving data during a travel reservation 
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purchase routine. The method includes the steps of monitoring data streams of at least one data 
sequence relevant to the travel reservation purchasing routine, and identifying a predetermined 
data stream in the data sequence. Once the predetermined data stream has been identified, a 
travel insurance purchase routine is executed. The routine includes the steps of 1) launching at 
least one form with data fields that are to be completed related to purchasing travel insurance; 
and 2; populating at least a portion of the data fields with data previously entered during the 
travel reservation purchase routine. A travel insurance policy is then generated. 
[0010] These and other aspects of the invention are not intended to define the scope of the 
invention for which purpose claims are provided. In the following description, reference is made 
to the accompanying drawings, which form a part hereof, and in which there is shown by way of 
illustration, and not limitation, a preferred embodiment of the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0011] Reference is hereby made to the following drawings in which like reference numerals 
correspond to like elements throughout, and in which: 

[0012] Fig. 1 is a schematic diagram of a workstation suitable for use with the preferred 
embodiment of the invention; 

[0013] Fig. 2 is a logical diagram of the communications of software components installed at the 
workstation illustrated in Fig. 1 ; 

[0014] Fig. 3 is a flow chart illustrating operation of a preferred embodiment of the invention; 
[0015] Fig. 4A is a flow chart illustrating the steps of an insurance purchase routine in 
accordance with the preferred embodiment; 

[0016] Fig. 4B is a flow chart illustrating the steps of the insurance purchase routine in 
accordance with an alternate embodiment of the invention; 

[0017] Fig. 5 is an illustration of a first screen generated when offering travel insurance in 
accordance with the preferred embodiment; 

[0018] Fig. 6 is an illustration of a pre-populated second screen generated when travel insurance 
is desired in accordance with the preferred embodiment; 

[0019] Fig. 7 is an illustration of a third screen offering various travel insurance packages in 
accordance with the preferred embodiment; 

[0020] Fig. 8 is an illustration of a fourth screen including an insurance cost calculator in 
accordance with the preferred embodiment; 

[0021] Fig. 9 is an illustration of a fifth screen including a travel insurance application in 
accordance with the preferred embodiment; 
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[0022] Fig. 10 is an illustration of a sixth screen including payment fields in accordance with the 
preferred embodiment; 

[0023] Fig. 1 1 is a sixth screen illustrating the issued travel policy in accordance with the 
preferred embodiment; and 

[0024] Fig. 12 is a schematic illustration of a travel insurance database in accordance with the 
preferred embodiment. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
[0025] Referring to Fig. 1, the present invention can be implemented on a workstation 20 
including a personal computer 22 having a central processing unit (CPU) 24. Processor 24 is in 
communication with a first network interface circuit 26 communicating over a network 35 with a 
mainframe computer 28, and with a second network interface circuit 27 communicating over the 
Internet 30 with a web server 29. The CPU 24 is further in communication with a video driver 
28, a keyboard interface 33, a nonvolatile memory device 31, and a volatile memory device 39. 
The video driver 28 is, in turn, connected to a display 32 that receives video data from driver 28 
and produces video output that is displayed to the user. The keyboard interface 33 receives input 
from a human/machine interface (HMI), such as keyboard 34 and/or mouse (not shown), and 
forwards the input data to processor 24. Nonvolatile memory device 31 stores an application 
program, such as a GDS 36, a conventional operating system 37, web browser 38, along with 
other software and data as known by those skilled in the art. A software package 40 constructed 
in accordance with the principles of the present invention is preferably installed on the computer 
22 locally and stored in memory 3 1 as illustrated, or is alternatively programmed on a central 
server (not shown) and executed by computer 22 communicating over a network. Volatile 
memory 39 can be a Random Access Memory (RAM) for temporarily storing data. 
[0026] Referring also to Fig. 5, operating system 37 is preferably a Windows® based system. 
Accordingly, display 32 can be a monitor including an active screen 41 including a GDS 36, and 
a taskbar 43. The term "GDS" is used herein to describe a system describing both a global 
distribution system and a computer reservation system "CRS" which are used by a travel agent 
when booking a travel reservation. It should be appreciated, however, that the principles of the 
present invention are not necessarily limited to GDS, but can apply to any computer program 
being executed on a computer 22 or workstation 20. Typically, information related to the 
identification of the travelers, travel itinerary, miscellaneous purchases (e.g., hotels, rental cars, 
etc.), and payment information are stored in the PNR and collected by the GDS. The most 
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common GDS systems are conventionally sold under the trade name designations of Sabre 
(Abacus in Southeast Asia), Amadeus, Galileo/ Apollo, and Worldspan. 

[0027] Referring now to Fig. 2, the communication of various components of computer 22 is 
schematically illustrated. In particular, the GDS 36 and software application 40 are both 
independently in communication with operating system 37. Software application 40 is in 
communication with the web browser 38, and operating system 37 is in communication with 
keyboard interface 33 and the Internet 30 via processor 24. 

[0028] The method of operation 49 of software application 40 will now be described in greater 
detail with reference to Fig. 3. Method 49 begins at step 50, where the software application is 
launched manually by the user or, more preferably, automatically launched upon start-up of 
processor 24 (i.e., when the computer 22 is first turned on). At step 52, software 40 runs in the 
background and monitors the processor 24 to detect the initiation of GDS 36. At decision block 
54, it is determined whether the GDS has been launched. If not, software 40 continues to 
monitor the processor 24. Once software 40 detects that the GDS 36 has been launched at 
decision block 54, the software 40 becomes active at step 56 and runs in the background in 
parallel with the GDS 36. Software 40 preferably resides on the taskbar of the user's display 32. 
[0029] During operation of the GDS, the keyboard interface 33 receives data input in the form of 
keystrokes entered by the user at keyboard 34 and places that data in a keyboard buffer (not 
shown), which can be part of or separate from interface 33. The keyboard buffer is maintained 
by the operating system 37 and is readable and writable by all applications running on the 
computer, despite the fact that the applications may themselves be incompatible. Because the 
GDS uses the input data to update the PNR when booking a travel reservation, data input to the 
GDS can be used to identify progress that has been made when booking a travel reservation. 
[0030] Accordingly, at step 57, software 40 monitors the data input via keyboard interface 33, 
and stores data pertaining to a particular PNR in RAM 39. Software 40 can store all data entered 
or, alternatively, can only store predetermined fields of data that will be used during subsequent 
steps, as will be described in more detail below. Software 40 preferably includes any Applet, 
preferably a Java Applet or an Active X/VB Applet, or any alternative apparatus suitable for 
monitoring data input via keyboard interface 33. By tracking all data entered into the GDS, 
software 40 can identify a predetermined word or sequence of keystrokes that signifies a 
particular point during the travel reservation booking process indicating that the traveler is likely 
to make a travel-related purchase. 

[0031] At decision block 58, software determines whether the predetermined data has been 
entered, which can be any word sequence (at any point in time during the completion of the 
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PNR) in accordance with the present invention. However, because the software package 40 is 
designed to sell travel insurance, the most desirable point in time to launch window 90 occurs 
once the travel reservation sequence has progressed to the point that the traveler is ready to 
complete the travel sale and ripe to purchase travel insurance. In accordance with the preferred 
embodiment, software 40 recognizes a predetermined PNR data code, for example corresponding 
to "form of payment" at decision block 58, thereby signifying that the traveler is ready to 
complete the sale. Examples of alternative data entry in the PNR that may be pre-selected to 
launch window 90 may correspond to printing an itinerary, printing a ticket, or other data entry 
sequences as appreciated by one having ordinary skill in the art. 

[0032] Referring also to Fig. 5, once the predetermined data has been entered, method 49 
advances from decision block 58 to step 60, where a pop-up window 90 is launched in the active 
screen portion 41 of display 32 that reminds the travel agent to offer travel insurance to the 
traveler. In particular, window 90 queries whether the traveler wishes to purchase travel 
insurance at step 60, and provides "accept" and "decline" icons 91 and 93, respectively, which 
can be "hotlinks" that are selectable by the agent via a mouse or like data input device. The 
"accept" icon 91 is selected if the traveler wishes to purchase travel insurance from the provider 
of software 40. The "decline" icon 93 is selected if the traveler does not wish to purchase travel 
insurance from the provider. 

[0033] If insurance is declined, window 90 is closed at step 62, and the agent completes the 
PNR. A secondary confirmation window (not shown) may optionally be activated in the display 
41 upon selection of the "decline" icon 93 at step 62. The secondary window queries whether the 
traveler does not wish to purchase any travel insurance, or whether the traveler is obtaining travel 
insurance from a different travel insurance provider. Alternatively, a third icon can be included 
in window 90 that queries whether the traveler is purchasing insurance from another provider. 
[0034] If insurance is declined, a notice can also be placed on the itinerary and the invoice 
provided to the customer that the traveler has been offered, and has declined travel insurance. 
The notice can include contact information of the insurance provider in the event that the traveler 
wishes to purchase insurance in the future. Next, at decision block 63, software 40 determines 
whether the current PNR, for which travel insurance was declined, has been completed based on 
the data input to keyboard interface 33. 

[0035] If so, software 40 advances to step 65, and launches web browser 38 and forwards data 
over the Internet 30 to the web server 29 of the travel insurance provider. The forwarded data 
can include information related to the declined travel insurance, including the identification of 
the travel agency, travel agent, type of travel purchased, and whether the traveler elected to 
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purchase travel insurance from another provider. Data compiled at server 29 regarding travel 
insurance policies offered can be organized into a database, as will be described in more detail 
below. 

[0036] Next, at step 67, software 40 clears RAM 39 of all data previously stored at step 56 for 
the previous PNR at step 67 and proceeds to step 57, whereby data pertaining to the next PNR is 
monitored and stored in RAM 39. A notice may also be placed on the itinerary and the invoice 
provided to the customer, along with contact information of the travel insurance provider. 
[0037] If the user chooses to accept travel insurance at decision block 61, the travel agent selects 
the "Accept" icon 91 and software 40 executes a "purchase travel insurance" routine 64. 
Referring to Fig. 4A, and also to Fig. 6, routine 64 begins at step 66, whereby software 40 
launches a window 92 presenting a form including a plurality of fields that are to be completed. 
For instance, the fields include identification information for each traveler, along with the credit 
card or other purchasing information for the primary traveler, and itinerary information for the 
travel package. It should be appreciated, however, that credit card information could be entered 
at other steps during routine 64, as described in more detail below. 

[0038] Software 40 identifies data, stored in RAM 39, that was previously entered into the PNR 
by the travel agent when booking the travel reservation. Software then captures the previously 
entered data that is also suitable for completing data fields in window 92, and pre-populates that 
data into the appropriate fields of window 92 at step 70. Accordingly, window 92 is partially 
completed when presented to the travel agent, thereby avoiding the need to enter data 
redundantly. As a result, when window 92 is displayed, the travel agent need only verify the pre- 
populated data, make necessary modifications, and enter only that data needed to complete 
window 92 that was not previously entered during the travel reservation booking process. 
[0039] For instance, the agent then may either enter the payment information of the traveler at 
the appropriate fields of window 92, which preferably includes the traveler's credit card 
information, or alternatively may wait until an insurance package is selected before entering the 
payment information. Alternatively, if software 40 is configured to launch window 90 after the 
traveler's credit card information is entered in the PNR, window 92 could also be pre-populated 
with the traveler's credit card information, and require the travel agent only to verify the 
completed data in window 92. 

[0040] Referring now also to Fig. 7, once the data fields in window 92 have been completed, 
routine 64 advances to step 72, whereby a window 94 is generated and displayed to the travel 
agent. Window 94 presents several possible travel insurance packages 96 that a user may wish to 
purchase depending upon his/her individual needs based, at least in part, on the nature of the 
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travel reservation (e.g., cruise, flight, hotel, car rental). Next to each option 96 is a help link 98 
that can be selected by the agent and provides an easy and convenient interface to obtain a 
description of the corresponding travel option along with a pricing link 100. If the pricing link 
100 is selected, a calculator 102 is launched that the agent can use to determine the price of the 
insurance package being purchased, as illustrated in Fig. 8. 

[0041] Once the pricing has been completed, routine 64 advances to step 76, whereby a window 
104 is generated, and provides the formal application 103 for travel insurance, as illustrated in 
Fig. 9. The application can include data fields regarding the identification of each passenger 
being insured. The information previously captured regarding the primary traveler can be pre- 
populated in window 104. The remaining information needed for the application is manually 
entered by the travel agent. Next, at step 78, if the credit card information was not previously 
entered at window 92, a payment window 105 can be launched that enables the travel agent to 
enter the traveler's payment information 107, as illustrated in Fig. 10. Once the payment 
information is entered, software 40 processes the application at step 80. At step 82, the insurance 
policy 106 is generated and displayed as illustrated in Fig. 11. 

[0042] At step 83, software 40 launches the web browser 38 in the background, and establishes a 
connection with the web server 29 over the Internet 30. If the agent's computer 22 is not 
currently connected to the Internet, the software 40 can provide a reminder for the agent to open 
a connection. Otherwise, software can automatically wait until the next instance that computer 
22 is connected to the Internet to perform step 83. Once web server 29 has been successfully 
accessed, software 40 uploads information related to the travel insurance package, including a 
travel agent identification code, type of insurance purchased, cost of insurance, and commission 
earned by the travel agency from the insurance sale. 

[0043] As a result, the travel insurance provider will be notified whether travel insurance was 
purchased or not (and if not, whether the traveler purchased insurance from another vendor) for 
every travel package purchased. If an insurance package is purchased, the information provided 
to the web server 29 can be used by the insurance provider to log the insurance purchase. 
[0044] Referring now to Fig. 12, the insurance provider can also create a travel insurance policy 
database 108, based on information provided from software 40 to web server 29 pertaining to the 
travel insurance (if any) that was purchased. In one embodiment, software package 40 may also 
record statistical data related to the insurance sales. For instance, software 40 may track the 
number of instances that travel insurance was offered along with the number of instances that 
insurance was accepted or declined and, if accepted, which insurance packages were purchased. 
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[0045] Database 108 can reside directly on the web server 29, or on a computer that is accessible 
by the web server. Accordingly, database 108 can be accessed by each agency operating 
software 40 by accessing web server 29. In particular, agents of a given travel agency can enter 
the agent's or agency's authorization code and password to authenticate the identify of the party 
requesting information. Server 29 can then provide a statistical summary for the inquiring party, 
which can include the number of travel reservations sold, the number of travel insurance 
packages sold, total commissions earned from the sale of travel insurance packages, and 
commissions lost from travel insurance packages that were not purchased. The accounting 
statistics can be further broken down by agent within the agency to identify those salespersons 
that were most efficient in selling travel insurance packages. The agency can further request that 
the accounting statistics be provided over a predetermined period of time. Database 1 08 
therefore enables individual agencies to track their insurance sales and performance of their 
individual agents. 

[0046] Finally, at step 84, software 40 identifies which GDS system (for example Sabre, 
Amadeus, Apollo etc.) is being used for the travel reservation, and populates the PNR with travel 
insurance-related data that was previously entered during the travel insurance purchase routine 
64. For instance, at step 84, accounting information obtained during routine 64 (such as the 
insurance policy number, travel insurance price, or any other information entered during routine 
64) can be populated into the PNR at the appropriate data entry fields. It should be appreciated 
that the various GDS systems use on slightly different protocol for data entry. Software 40 uses 
the GDS identity to determine whether the GDS being used is compatible with the software. If 
so, the data can be uploaded directly into the PNR. Otherwise, the data can be sent to the 
keyboard interface 33 in the form of simulated keystrokes that are read by the GDS system. 
[0047] Referring now to Fig. 4B, steps for performing routine 64 are illustrated in accordance 
with an alternate embodiment of the invention that is similar to the steps illustrated in Fig. 4A. 
However, in Fig. 4B, routine 64 begins at step 66, whereby software 40 launches web browser 
38, which is connected to web server 29 via Internet connection 30. The agent can input the 
agent's or agency's identification code so that the insurance provider recognizes the travel 
agency that is completing the insurance sale and can therefore update the database 108 
appropriately in the manner described above. The web sever 29 then launches window 92 as an 
applet, which is completed by the travel agent in the manner described above with reference to 
Fig. 4A, the difference being that the window 92 is executed on the web server 29 as opposed to 
locally on software 40. Steps 70-82 are also completed in the manner described above, with the 
various windows residing on the web server 29. Because information entered by the agent into 
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the various windows is automatically forwarded to web server 29, step 83 of Fig. 4 A is 
eliminated in Fig. 4B as server 29 can automatically capture data that is to be stored in database 
108. 

[0048] It should be appreciated in accordance with an alternate embodiment of the invention that 
certain windows 92, 94, 102, 104, and 105 can be launched directly by software 40, while others 
can be launched at the web server 29. Accordingly, unless otherwise specified, the various travel 
insurance purchase-related windows are not to be construed as limited to being executed locally 
on software or web server 29, but should be interpreted broadly as any window that 1) is 
configured to receive travel insurance related information using data previously entered into the 
PNR; and 2) can be used to populate the PNR once the travel insurance package has been 
purchased. Information entered locally on computer 22 that is necessary for producing database 
108 can be uploaded to web server 29 in the manner described above. 

[0049] Once the policy has been generated at step 82, routine 64 advances to step 84, whereby 
software 40 identifies the GDS system being used on computer 22, and forwards that information 
to the web server 29. Based on the GDS system, server 29 customizes the data into PNR data 
compatible with the GDS system. Software 40 receives the data from server 29, and enters the 
data into the GDS in the manner described above. 

[0050] Accordingly, software 40 advantageously provides an interface between the GDS system 
and the travel agent to provide a user-friendly method and apparatus for reminding the travel 
agent to offer travel insurance to the traveler, and for declining or accepting the travel insurance. 
If accepted, the system then provides a windows-based interface for the entering data pertinent to 
the travel insurance package. It is further advantageous that data previously entered into the PNR 
is pre-populated into the insurance application data fields, thereby increasing the data entry 
efficiency compared to conventional systems, which require that data previously entered during 
the travel reservation process be re-entered when purchasing travel insurance. It is further 
advantageous that the travel insurance purchase routine is not launched until 1) sufficient data 
has been entered into the PNR to indicate that the prospective traveler will indeed be purchasing 
a travel reservation and 2) a sufficient amount of data has been entered to enable the travel 
insurance application to be substantially pre-populated with data. It is further advantageous that 
software 40 populates the PNR with data entered during the insurance purchase routine to avoid 
redundant and time-consuming data entry. It is further advantageous that the methods described 
herein can be performed regardless of the compatibility between software 40 and the particular 
GDS being run on the travel agent's workstation 20. It is further advantageous that the software 
40 can communicate travel insurance-related data to a central web server which, in turn, produces 
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a database that can be accessed by an individual travel agency to view statistical information 
related to that agency's success in selling the insurance. 

[0051] The present invention thus solves a long-felt need in the travel industry for automatically 
encouraging high-commission sales while reducing time and effort on the part of the travel agent. 
[0052] It should be appreciated, however, that the principles of the present invention are 
applicable beyond the travel insurance industry, and can be used to enhance the real-time sale of 
any product or service. In particular, the principles of the present invention are equally 
applicable to other industries that would benefit by a software program of the present invention 
that is operable to automatically monitor data in real-time and run a process upon detection of a 
predetermined data entry sequence. Alternatively, or in addition to launching the operating 
sequence based on input data, the software can monitor the video driver 28 or any other data 
sequence between the data input and output for a predetermined data stream that indicates the 
timing is appropriate for the process to be launched. For instance, method 49 could advance 
from decision block 58 to step 60 if the video driver sends signals to the display 32 indicating 
that the data corresponding to the predetermined PNR code has been entered. Accordingly, 
unless otherwise indicated, the term "data sequence" is not intended to be limited to monitoring 
input data, but can include any data between the input and the output that results, at least in part, 
from the input data. 

[0053] The invention has been described in connection with what are presently considered to be 
the most practical and preferred embodiments. However, the present invention has been 
presented by way of illustration and is not intended to be limited to the disclosed embodiments. 
Accordingly, those skilled in the art will realize that the invention is intended to encompass all 
modifications and alternative arrangements included within the spirit and scope of the invention, 
as set forth by the appended claims. 
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